Zum Hauptinhalt springen

Leitfaden: Wann Daten wo hin - Listen

CertHub trennt Listeninformationen in vier verschiedene Module: Global Elements, Data Collections, Single Product Data Lists und QM Listen. Jeder Typ erfüllt einen anderen Zweck und stellt konsistente, wiederverwendbare und gut strukturierte Daten sicher. Dieser Leitfaden erklärt, wann du Daten in welches Modul platzieren solltest und bietet eine Checkliste, um dir bei der Entscheidung zu helfen.

Listen - wo pflegst du sie?​

1. Global Elements​

Verwende Global Elements, wenn die Information…

  • nicht produktspezifisch und nicht prozessspezifisch ist.
  • nicht Teil einer spezifischen Technical Documentation (TD) Datei ist.
  • nicht aus einem QMS-Formular oder Record stammt.
  • stabiles organisatorisches Wissen repräsentiert.
  • unabhängig von Produktvarianten oder -konfigurationen ist.
  • unternehmensweite Standards, Terminologie oder Definitionen beschreibt.

Beispiel: Firmenadresse, Glossar, Anforderungen

2. Data Collections​

Verwende Data Collections, wenn die Information…

  • für mehrere Produkte relevant ist.
  • zentrale Wartung über mehrere Produkte hinweg benötigt.
  • jedem Produkt ermöglichen sollte, eine Teilmenge der Items auszuwählen.
  • produktübergreifende Listen repräsentiert.
  • nicht aus einem QMS-Formular kommt.
  • für aktuelle und zukünftige Produkte wiederverwendbar ist.
  • Produktteams ermöglicht, Einträge wiederzuverwenden, ohne sie neu zu erstellen.

Beispiel: Fertigungsstandorte über Varianten hinweg, Lieferantenliste

3. Multi KTs​

Verwende Multi KTs (Datenlisten für ein einzelnes Produkt), wenn die Information…

  • nur für ein einzelnes Produkt gilt.
  • nicht über andere Produkte hinweg wiederverwendet wird und daher keine zentrale Wartung benötigt.
  • nicht aus einem QMS-Prozess oder Record stammt.
  • einzigartige Details eines einzelnen Produkts erfasst

Beispiel: Installationsanweisungen, Funktionselemente

4. QM Listen​

Verwende QM Listen, wenn die Information…

  • durch eine QMS-Formularübermittlung erstellt wird.
  • in einem auditierbaren QMS-Record (ISO 13485 / MDR) resultiert.
  • zu einem QMS-Prozess gehört (CAPA, Supplier Evaluation, Training, Audit, etc.).
  • nicht Teil der technischen Datei eines Produkts ist.
  • operative Qualitätsmanagementdaten repräsentiert, nicht Produktattribute.
  • nur durch formularbasierte Workflows gepflegt oder aktualisiert wird.
  • Teil einer kontrollierten QMS-Aktivität ist (z.B. Abweichungen, Genehmigungen, Änderungen).
  • immer nachverfolgbare, record-basierte Beweise erstellt.

Beispiel: Liste aller Beschwerden ab Januar 2025 für Produkt Sterilizer 20A

Data Collections vs. Multi KTs

Es ist eine Unternehmensentscheidung, ob Produktdaten in einer Data Collection (Master-Liste) oder unter einem einzelnen Produkt gepflegt werden.
Theoretisch können alle Multi KTs unter einem einzelnen Produkt als Data Collection modelliert werden und umgekehrt. Beide Versionen können je nach deinem Fall Sinn machen.
Generell, wenn du nur 1 Produkt hast, würdest du keine Data Collections verwenden!

Keine Liste?​

Wenn deine Daten keine Liste sind, bestimme, ob es Produktinformationen, Externe Daten oder QM Records sind.

Produktinformationen - ein einzelnes Feld​

Verwende Single KTs (Produktinformationen), wenn die Information…

  • produktspezifische Information ist (z.B. Intended Use, Produktattribute).
  • nur zu einem einzelnen Produkt gehört.
  • in einem Knowledge Template (KT) gespeichert werden sollte.
  • auch zu Product Properties gehören könnte (prüfe dort zuerst).

Beispiel: Intended Use, Risk Class (Product Properties), etc.

Externe Daten​

Verwende Externe Daten, wenn die Information…

  • eine externe Datei ist (z.B. Bilder, PDFs, .docx Dateien).
  • nicht auf Datenebene innerhalb von CertHub gepflegt werden muss.
  • zu einem spezifischen Objekt gehört (z.B. Prozess, Dokument oder Submission) — hänge sie direkt an dieses Objekt an.

Beispiel: Produktbilder, PDF-Anhänge, Legacy-Dokumentation

QM Records​

Verwende QM Records, wenn die Information…

  • als QM Records gepflegt und erstellt werden muss.
  • durch Form Templates erstellt werden sollte (Templates mit Eingabefeldern zum Ausfüllen).
  • in QM Listen resultiert (eine kompakte Ansicht aller ausgefüllten Formulare aus demselben Form Template).

Beispiel: Complaint Records (basierend auf dem Complaint Form Template), CAPA Records, Audit Records

QM Listen vs. Form Templates

QM Listen sind eine kompakte Ansicht aller Records, die aus demselben Form stammen.
Zum Beispiel ist "All Complaint Records" eine QM Liste basierend auf dem Complaint Form Template.